home *** CD-ROM | disk | FTP | other *** search
/ The 640 MEG Shareware Studio 2 / The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO / clang / nn.zip / NNTP < prev    next >
Text File  |  1989-12-31  |  8KB  |  208 lines
  1. NNTP SUPPORT
  2. ------------
  3.  
  4. This file describes the NNTP support available in nn release 6.3.  The
  5. NNTP support was implemented by Rene' Seindal, seindal@diku.dk
  6.  
  7.  
  8. PREREQUISITES
  9. -------------
  10.  
  11. Before you can use the NNTP part of nn, you need to get and install the
  12. nntp-1.5 distribution with patches 1-3.  It is available from several
  13. ftp-sites in the USA.  It is also available on freja.diku.dk (ip
  14. 129.142.96.1) together with the nn 6.3 distribution.
  15.  
  16. You also need read-access to an NNTP-server.
  17.  
  18.  
  19. HOW IT WORKS
  20. ------------
  21.  
  22. NNTP is supported both in nn and nnmaster.  When NNTP is used, the
  23. database with the header information used by nn is still maintained on
  24. the local system (because NNTP does not know about the nn database
  25. (yet?)).
  26.  
  27. When the master is set up to use NNTP, it will connect to the NNTP-
  28. server in each iteration of the collection (the interval set with -r),
  29. get a copy of the active file, and incorporate the new articles into the
  30. database.  To do this, the master will temporarily transfer one article
  31. at a time from the NNTP-server to the local system.
  32.  
  33. When the articles are read with nn, it will use the local database to
  34. present the menus, and fetch the articles from the NNTP-server as they
  35. are requested by the user.  It will connect to the NNTP server the first
  36. time it is necessary to fetch an article.
  37.  
  38. Neither nnmaster, nor nn will use NNTP if they run on the NNTP-server
  39. itself (they will directly access the news files).
  40.  
  41. Both nn and nnmaster access the server in reading mode.  The master and
  42. all client MUST use the same server at all times, since the local
  43. database contains article numbers, that are only unique for each
  44. NNTP-server.
  45.  
  46.  
  47. SHARING THE DATABASE
  48. --------------------
  49.  
  50. You must also decide whether you want to share the database between your
  51. local news clients, and how you are going to do it.
  52.  
  53. The database will take up some disk space, normally about 1Mb per 10.000
  54. articles.  There are several ways to manage this space.
  55.  
  56. This simplest solution, is to let each client run it own master, i.e.,
  57. have its own database.  This means, of course, no sharing.
  58.  
  59. Alternatively, one host can run the master, and distribute the database
  60. to the others via e.g., rdist.  This doesn't save disk space, but saves
  61. load on the NNTP-server.
  62.  
  63. Last, the database can be shared with NFS/RFS (see the description of
  64. NETWORK_DATABASE in the config.h file).
  65.  
  66. The possibility of making a `nndb-server' stands open.  It could be
  67. realized either as a separate server, running under inetd, or it could
  68. be incorporated into nntpd.  It has not been implemented, but might be
  69. part of a future release (any volunteers?).
  70.  
  71.  
  72. CONFIGURATION
  73. -------------
  74.  
  75. To use NNTP in nn, you must edit the relevant parts of config.h:
  76.  
  77. NNTP
  78.     You enable the use of NNTP by defining the macro NNTP.
  79.  
  80. NNTP_SERVER
  81.     Both the master and the clients will look up their NNTP-server
  82.     in the file given by the macro NNTP_SERVER.  If the name is not
  83.     an absolute path name, it is taken to be relative to
  84.     LIB_DIRECTORY.
  85.  
  86.     The format of the file is compatible with the one used in
  87.     clientlib.c in the nntp-1.5 distribution, i.e., the first
  88.     non-blank line, not starting with '#' is taken to be the name of
  89.     the NNTP-server.  This file MUST be present, and must contain a
  90.     valid host name.
  91.  
  92. NNTP_POST
  93.     If you use the NNTP based inews (part on the NNTP distribution)
  94.     and you have hosts that are not allowed to post to the NNTP
  95.     server, you should defined this.  It will make nn check at
  96.     connect time whether the NNTP server allows postings, and reject
  97.     all attempts to post, if the server disallows posting.  If you
  98.     do not define this, users will be allowed to post by nn, but the
  99.     posting will eventually fail.
  100.  
  101.     Again, this parameter is only relevant, if you use the NNTP
  102.     based inews, and have hosts that are not allowed to post.
  103.  
  104.  
  105. TUNING
  106.  ------
  107.  
  108. Both the server and each client maintains a cache of recently accessed
  109. articles, to minimize communication with the server (mainly to avoid
  110. fetching large digests continuously).  The master needs the cache when
  111. it splits digests, and the clients need it, because nn has a tendency to
  112. reopen the articles several times.
  113.  
  114. The master's cache is kept in LIB_DIRECTORY, and each client's cache are
  115. kept in the users .nn directory.  The constant NNTPCACHE (defined in
  116. nntp.c but can be redefined in config.h) defines the size of the cache,
  117. whose optimal size depends on the amount of news kept on line on the
  118. NNTP-server.  Values of 5-10 gives reasonable results.  The effect is
  119. most striking when reading digested news.
  120.  
  121.  
  122. INSTALLATION
  123. ------------
  124.  
  125. Making and installing nn using NNTP does not differ from a non-NNTP nn
  126. installation, except for the differences in the configuration and the
  127. need to specify the NNTP server in the NNTP_SERVER file.
  128.  
  129. Notice however, that the NNTP_SERVER file must be properly initialized
  130. before doing the 'make initdb'.
  131.  
  132. If something goes wrong in the initialization of the database, you will
  133. have to run 'nnmaster -I' again by hand.
  134.  
  135.  
  136. ERROR HANDLING
  137. --------------
  138.  
  139. The handling of errors have been improved since the initial release.
  140.  
  141. The master will handle most errors by closing the connection, and
  142. returning to the main loop.  All errors in the master are logged, with a
  143. code of `N,' so they can be inspected with the (undocumented?) `n'
  144. command in nnadmin's Log menu.
  145.  
  146. A few errors are considere fatal. If any of these occur operation will
  147. be discontinued.  These errors are such as failure to find the NNTP
  148. server, failure to find the NNTP service, and responses from the NNTP
  149. server in the 500 range (ill-formed requests, access denied, ...)
  150.  
  151. NNTP server timeouts are handled specially.  If the NNTP server times
  152. out, both nn and the master will attempt to restart it (by connecting
  153. again).  This shouldn't happen in the master (which won't leave sockets
  154. idle for that long), but it can easily happen in nn, if it is left
  155. suspended for too long.  If the server responds with code 400 (Service
  156. discontinued), a reconnect is also tried.
  157.  
  158.  
  159. PROBLEMS
  160. --------
  161.  
  162. I am not certain what should happen if the server sends back responses
  163. in the 1xx range.  I do not know whether a NNTP server is allowed to
  164. return one of these responses on its own initiative.  If it is, nn
  165. should probably ignore (or display) the messages.  Currently, nothing is
  166. done to treat these responses in any way.
  167.  
  168. I have seen a strange thing happen to the master, which I have not been
  169. able to reproduce.  The master ran on a Sun-4 running SunOS 4.0, and the
  170. NNTP server was a VAX 785 running MORE/bsd.  The NNTP software was
  171. version 1.5.3.  The master was stuck in a read from the NNTP server.  A
  172. netstat on the Sun show an established connection to nntpd on the Vax,
  173. but a netstat on the Vasx did not show any NNTP connections.  There was
  174. no nntpd running, and no messages on the console indicating any
  175. failures.
  176.  
  177. If you see this happen, please compile nntp.c with the macro DEBUG
  178. defined, and relink the master.  The master will then leave a transcript
  179. of the conversation between the master and the NNTP server in
  180. /usr/tmp/nnmaster.log.  If the master gets stuck again, save this file
  181. before you restart the master, and send it to me.  The file is truncated
  182. each time the master connects to the NNTP server, so it won't fill up
  183. your disk.  If you compile nn with nntp debug enabled, it will be a very
  184. annoying program, so you probably don't want to do that.
  185.  
  186.  
  187. ALTERNATIVES
  188. ------------
  189.  
  190. Alternative implementations can be conceived, especially in the master.
  191. The master normally collects articles by rereading the active file,
  192. looking for changed article numbers.  For each group with new articles,
  193. it reads the new articles and adds them to the database.  This scheme
  194. has been kept in the NNTP-based master, to keep the changes at a
  195. minimum.
  196.  
  197. An alternative solution could be to use NEWNEWS to get a list of new
  198. articles since last collect, and fetch each article in sequence.  The
  199. newsgroups and article numbers within each group could then be found in
  200. the Xref: field.  This would probably improve efficiency, since the
  201. master would then generate fewer failing requests (for non-existent
  202. articles), and it would only read cross-posted articles once.  This
  203. solution would, however, require some surgery on the current structure
  204. of the masters main loop.
  205.  
  206. Suggestions and improvements are very much welcome.  Send your ideas or
  207. contributions to nn-bugs@dkuug.dk.
  208.